home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
acct
/
acct-minutes-90dec.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
7KB
|
194 lines
CURRENT_MEETING_REPORT_
Reported by Cyndi Mills/BBN
ACCT Minutes
Agenda
Review and Revise:
Document
o Internet Accounting Background Editor: Don Hirsh,
hirsh@meridiantc.com
o Internet Accounting Architecture Editor: Cyndi Mills,
cmills@bbn.com
o Internet Accounting Meter Services Editor: Mark Seger,
seger@asds.enet.dec.com
o Internet Accounting Collection Protocols Editor: Martin Dubetz,
dubetz@wugate.wustl.edu
Action Items:
Changes during review and revision:
1. Distinguish between Internet (long-distance) and local-area
accounting. Internet accounting does not use attributes or
user-ids (this reduces overhead). Local area accounting may use
attributes and user ids (these may be defined later). The same
accounting record formats are used for both Internet and local area
accounting, although different profiles define which fields are
mandatory, optional, and prohibited for each type.
2. Refined ENTITY definition to be:
oEnd-system network addresses.
oIntermediate system network addresses.
oAllow for different address types (IP address, NSAP address,
etc.)
oAll addresses are now absolute (no longer relative to meter
loc).
What about dynamically allocated network addresses (transients)?
1
At least the service provider must be identified, if not the
individual host. Could service provider allocate IP address as
unique subscriber identifier independent of transient address?
Added a comment or unique id field which may be appended to the
entity for use as an additional identifier. Local area accounting
only, please. We need a mechanism to map transients tounique ids,
but don't want to get involved in defining a directory service with
real time propagation problems. Maybe we should simply provide an
appropriate field for use in the accounting record without
specifiying how mapping is obtained. This discussion should be
continued on the mailing list.
3. VALUES -
Counters don't reset to zero on reporting, so we are consistent
with SNMP. Need to make sure this can work without too much
additional memory from router. Don't want to copy too often or
maintain multiple ``snapshots'' of accounting tables in routers.
4. In background document, need to explain:
oMulticasting is collected as an address. No special
consideration. Dropped packets are tough luck - they may be
counted and we can't distinguish retransmits at the IP level.
Treat as performance problem, not accounting problem. Network
management should use other measures for dropped packets and
guaranteed levels of service, etc.
oExplain hierarchical collection better. Each network generally
accounts for its immediate subscribers, which may be
end-systems (hosts) or other networks (routers or broadcast
media with a network number). Explain importance of
recommending collection at internet entry and exit points
(rather than at all routers) to minimize accounting overhead.
oMake it even clearer that this group isn't recommending billing
approaches. How administrations bill (flat fee, cap, minimum,
guaranteed delivery rates, penalties) is far beyond the scope
of what we're trying to accomplish - we're just looking for a
reliable way to report on network-layer network usage!
(express goals/non-goals more emphatically)
5. Distributed rewrites/comments/updates of Architecture, Meter
Services, and Collection documents.
6. Collecton protocol discussion. Need help on deciding whether SNMP
will be adequate - performance issues may be key. Certainly SNMP
authentication is an issue. However, SNMP is the management
protocol of choice, and is most widespread.
7. List of questions for Security Area, particularly regarding SNMP.
Need help from Security Area.
oPerformance of authenticated SNMP? Single-stream/multi-stream?
oAuthentication: do we need to add signatures for our meter
ids? Will SNMP ``just take care of this''?
2
oAuthorization: how do we tell our routers which management
stations (plural) are authorized to collect information.
(Access control). I suppose someone will have to think about
who can get the information from the collection point. How do
we resolve this in light of having one ``control'' station and
multiple ``monitoring'' stations for each router. How do we
transfer title to ``control'' station when the original control
station crashes, gets isolated, etc. Does SNMP do access
control? ACLs (access control lists)?
oConfidentiality: We need encryption for sensitive traffic flow
information. Will SNMP do this for us, and key management too?
oIntegrity: Even if we don't need encrypted data, how about
encrypted checksums? What will SNMP do for us here?
oDenial of Service. What do we need to worry about here?
oExport controls. Do we need to define multiple variants of
encryption? Can we do this and still meet performance and
other goals?
oGoverment security requirements. How to ensure that this will
meet both commerical and government requirements?
Currrent Action Items:
1. Enlist security help.
2. Enumerate COLLECTION ISSUES (revisited) and post to list.
3. Explain how SNMP might work and ramifications.
4. Finish Updating Architecture document, distribute to list.
5. Revise Meter definition document and distribute to Working Group
list.
6. Revise Background document and distribute to list.
7. Write MIB (add to Meter Services).
8. Estimate number of concurrent flows on backbone, e.g., NSFnet HTM.
9. Submit outrageous statements to email list if it's quiet for too
long to provoke resumption of appropriate discussion.
Overall Timetable:
o Update current document set for storage in IETF-DRAFT ASAP.
o Meet in January/February to expedite MIB definition.
o Discuss collection issues on mailing list - after some discussion
submit synopsis to ietf mailing list to solicit help from a wider
audience.
3
Attendees
Robert Collet /PN=ROBERT.D.COLLET/O=US.SPRINT/ADMD=TELEMAIL/C=US/@sprint.com
Robert Cooney cooney@wnyose.nardac-dc.navy.mil
Fred Engel
Mike Erlinger mike@mti.com
Brian Handspicker bd@vines.enet.dec.com
Don Hirsh hirsh@meridian.uucp
Ken Jones uunet!konkord!ksj
William Kutz Kutz@dockmaster.ncsc.mil
Cyndi Mills cmills@bbn.com
Chris Myers chris@wugate.wustl.edu
Fred Ostapik fred@nisc.sri.com
Bill Rust wjr@ftp.com
Mark Seger seger@asds.enet.dec.com
Michael St. Johns stjohns@umd5.umd.edu
Jesse Walker walker@eider.enet@decpa.dec.com
Kathy Wilde wilde@decvax.dec.com
David Wood dcmwood@spot.colorado.edu
Lixia Zhang lixia@parc.xerox.com
4